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ABSTRACT 

This paper describes the design and implementation of a low-cost PACS conforming to the DICOM 3.0 standard 
The goal was to provide an efficient image archival and management solution on a heterogeneous hospital network 
as a basis for Rimless radiology. The system fallows a distributed, client/server model and was implemented at s 
fraction of the cost of a commercial PACS. It provides reliable archiving on recordable CD and allows access to 
digital images throughout the hospital and on the Internet. 

Dedicated servers have been designed far short-term storage, CD-based archival data retrieval and remote data 
access or teleradiology The short-term storage devices provide DICOM storage and query/retrieve services to 
scanners and workstations and approximately twelve weeks of 'on-line' image data. The CD-based archival and 
data retrieval processes are fully automated with the exception of CD loading and unloading. The system employs 
lossless compression on both short- and long-term storage devices. All servers communicate via the DICOM protocol 
in conjunction with both local and 'master' SQL patient databases. Records are transferred from the local to the 
master database independently, ensuring that storage devices will still function if the master database server cannot 
be reached. 

The system features rules-based work-flow management and WWW servers to provide multi-platform remote 
data access. The WWW server system is distributed on the storage, retrieval and teleradiology servers allowing 
viewing of locally stored image data directly in a WWW browser without the need for data transfer to a central 
WWW server. An independent system monitors disk usage, processes, network and CPU load oa each server and 
reports errors to the image management team via email. 

The PACS was implemented using a combination of off-the-shelf hardware, freely available software and applica- 
tions developed in-bouse. The system has enabled filmJess operation in CT. MR and ultrasound within the radiology 
department and throughout the hospital. The use of WWW technology has enabled the development of an intuitive 
web-based teleradiology and image management solution that provides complete access to image data 
Keywords: PACS. DICOM, recordable CD. image management. Aimless radiology 
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ABSTRACT 

This piper describe* the incorporation of radiology teaching files within oar existing fiUnJess radiology Picture Archiving 
and Communications System (PACS). The creation of teaching files employs an intuitive World Wide Web (WWW) 
application that relieves the creator of the technical details involving the underlying PACS and obviates the need for 
knowledge of Internet publishing. Currently, our PACS supports filmless operation of CT, MRI, and ultrasound modalities, 
conforming to the Digital Imaging and Communications in Medicine (DICOM) and Health Level 7 (HL7) standards. Web- 
Ssssed r—^ing files arc one module in a suite of WWW tools, developed in-house, for platform independent management of 
radiology data. The WWW browser tools act as liaison between ^expensive desktop PCs and the DICOM PACS. The 
creation of a teaching file is made as efficient as possible by allowing the creator to select the images and prepare the text 
within a single appUcadon. while finding and reviewing existing teaching files is simplified with > flexible, multi-cntens 
searching tool. This efficient and easy-to-use interface is largely responsible for (he development of a database, currently 
containing over 400 teaching files, that has been generated in a short period of time. 

Keywords: teaching files, world wide web, filmless radiology, PACS 
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1. INTRODUCTION AND BACKGROUND 

The Department of Radioiogy at ibe Montreal General Hospital (MGH) provide, radiological service* for our 500-bed. level- 
1 trauma centre, as weU as for external clinics in neighbouring hospital* such as the Royal Victoria Hospital and the Montreal 
Jewish General Hospital. Our department has been in fihnless operation since February of 1997 for CT and MR, and since 
October of 1995 for ultrasound. Since then, the department has performed approximately 72,000 filmless exams in these 
modalities To accomplish this, a modular PACS was developed in-house to provide connectivity between scanners, 
commercial workstations, and storage servers for on-line and off-line data. As well, a recent development has allowed us to 
interface our PACS with the Hospital Information System (HIS) and we are currently developing our own Radiology 
Information Service (RE) to provide electronic reporting rmtctionality conforming to HL7 standard!. A WWW server 
provides access to our PACS for computers with Internet connectivity. This allows non-OICOM clients (such as inexpensive 
PCs) to view images and reports, issue DICOM move conunands, print to paper, and issue pre-fetcMng instructions to the 
system. 

The distributed DICOM storage servers are based upon ^expensive Intel-Pennum platforms running a public domain 
variant of UNDC called LINUX. DICOM conformance is achieved by developing tools employing the Mallinckrodl Insritute 
of Radiology Central Test Node (CTN) library, and a public domain database (Mini SQL, Hughes Technologies ) a used to 
store patient and image information. We currendy employ four such servers (called modality servers) for three CT scanners, 
one MR imaging scanner, and nine ultrasound acquisition stations; while two servers provide archiving and off-line retrieval 
ecrively.fi] 



Only modality servers receive images directly from the scanners (i.e., scanners never send images directly to 
workstations), since only modality servers update a master database which tracks the loca&oofs) of every image in the system 
along with all its relevant information. These modality servers are equipped with five 9 G8 disks in a levcl-5 RAID amy to 
serve is short term on-line storage facilities (typically 12 weeks), which support the DICOM Storage and Query/Retrieve 
service classes as both provider (SCP) and user (SCU).[2] As well, they automatically route images to specific workstations 
based on modality and anatomy, which is how our radiologists are organised. Additionally, a copy of the image is routed to 
the archival server to be placed on compact disc recordable (CD-R) media for long term storage. 



RICR.(cormpondence): Email: mibm@radrnghancgill.ca; Telephone: 514-537-601 1 ext. 3386; Fax: 514-934-8229 
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2. IMPLEMENTATION 

Our teaching file server became fully operational in September 1997 b-^^MO JJjJ^ 

-^^^ 

all wteracnonispitrvidedbyawebservw, 

Teaching file dau and web access to the teaching file, are totalised to one server <»*°" Jf ^JT? P|S^ 
— J^rKBJX The server is . DICOM storage SCP as well as a WWW server. Images moved from a modality server to 

may be used. 

Common Gateway Interface (CGI) scripts written in Perl, provide the tool, to create modify, 
1Mch ig file* As well they control access privileges to restricted function,. For instance, only me »ww*of.ie«hmgfi^ 
^™«with ownership rights may make modifications to • file or delete it and a guest account may not create a teaching 
file ^nc particularly useful tool, restricted to department members, is the ability to compile a group of teachmg file, and 
hTve SemSSSuy saved on a CD-R. This allow, vuiting radiologists to bring their with them when they leave 
^ aSmaH-c. film is not otherwise available. This also enables radiologist, to prepare rounds for facilities no. 
clipped with a network connection. 



3. DESCRIPTION 

The teaching file server was designed to fit in « part of a larger toolkit to allow web-based client, to interact with our 
filmiess PACS. In so doing, re-traming was not necessary except for those functions unique to creating M f™8 ™* * 
weU even though the teachmg file server is a phys.eally separate entity, the way m which a user uterus with the web too h 
appear, seamless. The interactions specific to teaching file, can be grouped into three categories: 1 -teachmg file creation, 2- 
teaching file search and review, and 3 -teaching file maintenance and utility. 

1 For a detailed discussion of our PACS design, please see our companion paper in these proceedings by R- D. Cox, eu a/., 
tided "DICOM-compliant PACS with CD-based image archival." 
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U. Teaching file eration 

The first step in creating a teaching a file is lo identify the senes of images that wij] be grouped within one file. Radiologists 
are also able !0 add scrapbooks (single senes collections of clinically significant annotated images) to leaching files, which 
are created on the review workstations and then pushed onto a modality server, which treats them as any other new senes it 
receives (i.e., updates the master database, creates JPEG image* and sends the files to be archived). To identify tad add any 
series to a teaching file, the creator first logs on to the teleradiokigy web server using a user name and password. A search 
utility allows the appro prate series to be found by descending a hierarchical listing of patients, studies, and then series. With 
a list of senes shown, the user selects one or more senes and chooses 'Create Teaching File' from a pull-down list of possible 
actions. If the user account did not posset* the right to create a teaching rile, this option would not be present As shown 
below in figure 1, the user has selected three scrapboolcr 1 . Just below tbe selection window, is a puil-doi 
to perform on the selected series. Here, ■Create Teaching File' is chosen, and when 'Submit' is clicke 
taken to a teaching file input form where textual and other information may be entered 



menu of actions 
clicked, the user will be 




A check is done to see if any teaching files already exists with die same unit number (medical record number) as any of 
the series being added. If one or several matches are found, a list is displayed and the option is presented to append the new 
series to one of the existing teaching files, or to create a new file (figure 2). 

If the option to append the new senes lo an existing file is chosen, the form is filled out automatically with the 
information from the teaching file. This is useful for progressively presenting a study. The input form consists of text input 
fields, pull-down menus and check-box fields. Patient information such is ige, sex and unit number, as well as the 
information about the images (modality, anatomy, name of physician) is automatically copied as well and shown at the top of 



1 Scrapbock modality is denoted as 'Other' (OT) 
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The creilor of the teaching file has twelve fields to fill qui, but oaiy tunc sjt input*. The text input fields are rot 
entering descriptions of clinical findings, descriptions of mage findings (figure 3), and a list of keywords delimited with the 
stun character ('/'). Keywords can ilso be selected from a list of previously entered keywords, sod that list is updated 
whenever a new keyword is adopted. The text inputs place oo restriction on the users concerning length or content A pull 
down menu with a list of exams is provided. For example, a MR abdominal case would have options such as: dermoid. MRA. 
spleen, etc.. If the radiologicai study is proven or unproved or if it needs foilow-up, this can be indicated with a check-box. 

Taacaaaw NNO JUmay Exist fm frl a tto d Dal Waaharfa) 




FtfBr* 2; Eibtijq; tw*l»i fU« fauwi roouicins; cbt «*it .amim of the nrw series. T%« user 
mmj saw create a new fik, or sepead the baafes to an exlstiaf am. 



If the creator is not a staff radiologist, but rather is a resident or a fellow, a pull-dowo mean of staff radiologists can be 
used to link one of them to the file, giving the staff member ownership rights. This list of staff radiologists is obtained from 
the main user database, and oo changes to the scripts are needed when new accounts are added or removed. Two text fields 
arc provided for ACR coding but, so far, not a single teaching file creator has entered information here. The consensus is that 
keywords, and the ability to search for them, are more meaningful and, hence, more useful to our radiologists. 
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Study interest and image quality can be ranked from I (lowest) to 5 (highest* by clicking the appropriate check box 
(figure 3) and the images can be flagged as being of print quality. This is important for our users wishing to search this 
facility to find interesting cases with high quality images for presentations and publications. 

When the teaching file creator is satisfied with the form, a button at the bottom of the page submits the information to a 
script on the teaching file server. The receiving script checks that certain fields are filled in, and if key information u 
missing, notifies the user and returns them to the input page to enter the missing information. Otherwise, the script begins 
searching the master database for the location of the images in the PACS and then issues DICOM move commands to the 
teaching file server from all the necessary modality servers. If images are only stored in off-line archives, the archive 
retrieval server win be instructed to retrieve and send the required images to the teaching file server. When the images arrive 
at the teaching file server, they are stored in DICOM format (12-bit data), and a JPEG format image is also created and 

The data from the input form is added to a database on the teaching file server, or in the case where an existing file is 
being modified, a database update is performed. The relational database is structured into individual tables for the teaching 
file text, image information, and a table of keywords. For each teaching file, there is one teaching file text table entry with a 
unique identification number. This identification number units one or more table entries m the image information tabic. The 
keyword table is independent, and is merely used to track the list of the current keywords being used 
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3.Z Teaching file search sod review 

Access is gained to the leaching file server through our login page od the teleradioiogy server. The users must identify 
themselves using a user name and password combination. Guests may me a generic account with few privileges beyond 
viewing teaching files, and patient names are withheld during any of the limited access to the rest of the system. 

The first page shown upon entry ts a menu of functions available to the user. The first menu item brings the user to a 
search facility shown in figure 4. This is presented aa a Oil -out form that allows users to build their queries. The form is 
designed to be as efficient as possible for entering queries ranging from simple to complex. The form can be logically 
divided into two parts. The top portion allows the user to build a sentence-like query by using pull-down menus and a test 
input field. The first menu contains a list of IS text-searchable fields, with 'Keywords at the top of the list and pre-selected 
since it is used most often. The next mean contains a list of logical statements: contains', ' begins with', 'is', 'is greater man', 
tad 'is less than'. By default, the 'contains' option is selected. Following these two means is a text entry field for the user to 
use to complete the sentence- Multiple items can be entered delimited by the '/* character, and the conjunction is a logical 
'or*. At this point, the user may submit the query, but there is the option to limit the results further by using the next line 
below which is similar to the first sentence-like query. The two can be combined in a logical 'and' or a logical 'or' function. 
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Figure 4: Tcaeaiag (lie search form. The reselling query of the form abort win select all leaching files thai have 
keywords containing 'liver' and cllatcal finding* con ti la lag 'eysf sad beloagiat to the abdaaolaaJ' I penality. 

The second portion of the query form is composed of check-box type input fields. These fields act as 'and' functions 
with the sentence-like queries. Using the check-boa inputs, the search can be limited to radiologist speciality (abdominal, 
bone, neurology, etc), exam status, usage quality, study interest and print quality. As well, a pull-down list of exam types is 
given. 

The page following the query form presents a list of teaching files matching the search criteria (figure 5). At this point a 
teaching file can be viewed, modified, deleted or marked for addition to a CD-R (assuming the account has all the proper 
privileges}. Guests may only view teaching files, and only owners may modify or delete a teaching file. 
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Figure 5: Ust of teaching met matcHing srarth criteria. 



Choosing to view a reselling file brings up a web page containing til the information of the chosen file. At the top is a 
hyper-link called 'View Series'. This will open a new window displaying the images of the series in a riled layout Controls 




Rgsrt 6: Teaching flic display. Skown are two ovcrtappiag wiadows. oat CMtaiaiag the imago tf the teaching flit 
tad tat orttr eonui»iog (be description. 



at the fop of the page allow the uier to modify the sue of the images, turn image numbering on and oft modify the image 
son order and adjust the brightness and contrast by entering new window and level values. When scout images are avwfable. 
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a single image or i whole sencs can be referenced to its corresponding scow to produce a scoot image with slice lines 
indicating the intersections of the images with the scout (figure 6). 

All the programs for viewing images, re-sorting, adjusting brightness aad contrast, and scoui referencing were recycled 
from the in-line viewing application of our web-based PACS interface. Therefore, do extra programming was required for 
this interface. In general the teaching file server was designed to took and behave much like the PACS interface to save 
development and training time. As an added benefit, many improvements or additions to the PACS application apply to tie 
teaching file server as well. 

3 J, Teaching file maintenance aad atfliry 

Managing teaching files is a task left to the staff radiologists, fellows and residents, with the exception of server specific 
issues. This includes content quality control aad maintaining the list of keywords. To help keep keywords as consistent as 
possible, a keyword database editor application allows for the removal, modification and the ability to coalesce similar 
keywords into one. This not only changes the list stored in the keyword database, but alters the keyword entries in the 
teaching files as well. For instance, changing 'abd. mass' to 'abdominal mass' will remove 'abd. mass' from the database 
and add 'abdominal mass* unless it already exists. All teaching files with keyword entries matching 'abd. mass will also be 
updated with the new keyword. This makes search results matching a single keyword more complete since multiple spellings 
and abbreviations are eliminated. 

One very useful feature ol our teaching file system is the CD-R creation facility. Over tune, any user with the proper 
privileges can mark teaching files to be placed on a personal CD. Selecting one or more teaching files from the query result 
list and choosing 'Add Teaching File to my CD-R' does this. Yet another database table keeps track of the CD selections of 
each user, as well as the amount of space required to store the selected leaching file. Eventually, the CD will reach capacity 
aad the user will be notified that no more files can be added to their current CD. The user may then choose to bum the CD as 
is or edit the contents using a simple interface. From the point of view of die user, having a CD burned requires just one 
button click from the main teaching file menu. This starts a script that looks up the contents of the CD and makes a copy of 
every image into a separate directory on disk. Then it make* one hypertext mark-up language (HTML) file for each selected 
leaching file containing all the teaching file information. Another HTML file is made for each image scries. Hyperlinks are 
added to link the image HTML file with the teaching information HTML file. Finally, aa index file is made, listing all the 
leaching files stored on disk with hyperlinks to each one. Unfornnutery. this replaces the web-based search tool since it is 
not possible to add it to the CD because all searching is done on the server side of a web connection. Included on the disk is 
a copy of Netscape for both Macintosh and Windows 95, so me CD is all the user needs to view the files on a desktop PC 
running these systems. 

Overnight, the CD image on die teaching file server is copied to a CD-R archive stanon and scheduled to be saved on a 
CD-R. By the following day, the CD-R is ready to be picked up. 

4. RESULTS 

Detailed statistics are kept by our web-based PACS application concerning actions performed by every user using the system. 
These statistics allow the system developers to monitor system activity to determine which features are most used, and 
therefore, may need performance improvements to keep pace with demand. Under-used functions could be explained in two 
ways. A function may not be well used because it simply is not needed, or it just may not function efficiently enough to be 
worth using. Jn any case, more than once, auditing usage trends have identified areas which need performance or interface 
improvements.'' In the event of any suspected misuse of the system, detailed audit trails are available for further 
investigation. 

The teaching file related functions also add to the history of usage statistics kept for the web-based PACS application. 
Examination of these records shows that there now are 577 image series belonging to 485 teaching files on the server. 20 
different users have created these since August of 1997. The median for new teaching files created per month is 53, and the 
median for the number of different creators per month a 7 (see graph I ). The break, down of teaching files by speciality is 
85% abdominal, 6% bone, 6% neurology, 2% spine, and 1% chest 



4 For a detailed discussion of the performance of our PACS, please see our companion paper in these proceedings by C, J. 
Henri, ft al, titled "Acquisition and analysis of usage and data-flow statistics for a DICOM-compliant PACS." 
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A total of 72 users have performed 1900 
number of queries per month is 376, and the 
month (see graph 2 below). 



queries using the teaching file search utility. The median for the 
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Graph 2: Teaching file qatrin by rooms 



5. DISCUSSION 



The results for the creation of new teaching ales show a peak of 2 1 3 in September ana thee tapered-off to a n 
level of around 50 new teaching files created per month. This is due to a batch conversion of teaching files stored in another 
database, which also explains the large skew of 85% abdominal speciality corneal The previous database was only for MR 
abdominal cases, and did not store any images. So the immediate benefit of converting the older fJes to the new web- based 
form was the addition of images as well as a m u ch broader potential audience (the previous database was o " 
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from Macintosh computers in our department). The creation of teaching files should remain somewhat constant Tor the nev 
future, since residents must now create new teaching files tn satisfy a quota that is part of their academic requirements. 

Teaching file queries also show a steady trend of just under 400 queries per month (median is 376). August has lev- 
queries because the teaching files server had only just been created. User queries for January 1998 are below average despite 
the fact that this paper is being written only two thirds of the way through the month. This is probably due to the lack of 
activity in the department because of holidays and a major ice storm that caused the city and outlying regions to loose power 
for several days. 

6. CONCLUSION 

Our web-based teaching file server has three distinguishing features that make it a powerful and useful tool. The first is 
integrating the server with our existing DICOM PACS. There is no need to cut and paste images from one application to 
another. Instead, the creator can build teaching Hies using lay series found is the muter database, using a single, and 
consistent interface that is simple and easy to use. The second important feature is that the teaching file becomes 
immediately available after creation to anyone with Internet access. Most importantly, the creator does not have to know 
anything about creating web pages or any of the derails concerning the location of images or the transfer of image series to 
the teaching file server. The third key feature of our teaching file server, is the fact that it was developed in-house along with 
our PACS. This allows the system to be tailored for the users by making modifications and introducing new features to keep 
pace with the ever-evolving requirements of the system. 
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ABSTRACT 

This paper describe the design and implementation of a low-cost PACS conforming to the DICOM 3,0 standard 
The goal was to provide an efficient image archival and management solution on a heterogeneous hospital network 
as a basis for filmiess radiology. The system follows a distributed, died/server model and was implemented at s 
fraction of the cost of a commercial PACS. It provides reliable archiving on recordable CD and allows access to 
digital images throughout the hospital and on the Internet. 

Dedicated servers have been designed for short-term storage, CD-based archival, data retrieval and remote data 
access or teleradiology. The short-term storage devices provide DICOM storage and query/retrieve services to 
scanners and workstations and approximately twelve weeks of 'on-line' image data. The CD-based archival and 
data retrieval processes are fully automated with the exception of CD loading and unloading. The system employs 
lossless compression on both short- and long-term storage devices. All servers communicate via the DICOM protocol 
in conjunction with both local and 'master' SQL patient databases. Records are transferred from the local to the 
mas ter Aft***"* independently, ensuring that storage devices will still function if the master database server cannot 
be reached. 

The system features rules-based work-flow management and WWW servers to provide multi-platform remote 
data access. The WWW server system is distributed on the storage, retrieval and teleradiology servers allowing 
viewing of locally stored image data directly in a WWW browser without the need for data transfer to a central 
WWW server. An independent system monitors disk usage, processes, network and CPU load on each server and 
reports errors to the image management team via email. 

The PACS was implemented using a combination of off-the-shelf hardware, freely available software and applica- 
tions developed La-house. The system has enabled filmiess operation in CT. MR and ultrasound within the radiology 
department and throughout the hospital. The use of WWW technology has enabled the development of an intuitive 
web-baaed teleradiology and image management solution that provides complete access to image data 



Keywords: PACS. DICOM, recordable CD. image management, filmiess radiology 
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1. INTRODUCTION 
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2. SYSTEM OVERVIEW 
2.1. Distributed versus Centralized 

Prom the outset, we chose to employ a distributed client/server design sr. our PACS development. This design 
provides several key advantages: 

• Data are distributed throughout tbe network, and with proper design, the miage data are already located wbn. 
they will be required. 

• There is no requirement for a 'super-server' to handle the emir? PACS ioad. as both network and computation*, 
load are distributed among several servers. 

• Servers can employ cheaper Hardware as they ao not need to be as powerful as. a single centralized server. 

• A distributed design can be easily scaled to suit growing demands by simply installing additional servers or 
expanding network segments to meet the need. 

. The PACS can be designed with redundancy of both data and hardware, reducing or eiuuiitating single points 
of failure. 

A major drawback of distributed PACS is the complexity of the design and implementation. Image data can or 
found in a variety of locations and the applications that access them must be able to choose the optimal source (or 
data they wish to transfer or process. This has increased the complexity of the developed system. Fortunately, this 
increase has remained transparent to the user community who see the PACS as a single entity Jn essence, the goai 
is to design a distributed system with ail its inherent advantages, but have it appear as a centralized system from 
the perspective of the user. 

While data storage and access arc distributed, It was necessary co design a central database to contain patient 
summary and image location information of all data scanned into the PACS network. This was done to relieve the 
user from having to know where in the system the image data reside. As image data are acquired and transform! 
from the scanner to a dedicated short-term storage device, or modality server, a summary of the given patient 
demographic, study and series information, and data location are transferred to this central database on the master 
database server. 

2.2. System Components 

Tbe PACS is based on UNIX servers and makes extensive use of Icev UNIX features such as stable multi-processing 
and memory management, the cron facility for launching background processes, and a variety of public-domain 
servers, interpreters and development tools. 

Figure 1 shows the features supported by each of the components of the PACS and the various interactions 
(DICOM. database and web-based) between them. 

2.3.1. WWW Server 

The primary user of the central database, is a full-featured set of web-based applications called the PACS browser 2 
With a web browser, a user can locate image data anywhere in tbe PACS network using a sophisticated search 
engine. Once located, images can be viewed within the browser, transferred to an alternate location such as a 
reporting workstation, printed on plain paper or downloaded at full resolution to a PC for off-line analysis. All data 
are transferred from source to destinati o n transparently; that is, without the user needing to know where the data 
currently reside. The sole exception to this is the case where the data can only be found in long-term storage. Coder 
these circumstances, the user is warned that the images will have to be retrieved from CD, as this procedure could 
take several minutes. 

The PACS browser has gainea wide acceptance and is used by «!very segment if the user community: 
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Figure 1. Shows features of various PACS components and interactions between them. 

• Radiologists use the system to manage image data on the PACS, review work lists of cases in their specialty, 
engage in physician consultation, perform on-cail review over a modem connection (teleradiology), and create 
teaching files' of interesting cases. 

• Residents use the system as a learning tool, while gaining much needed exposure to a film! ess radiology envi- 
ronment. 

• Technicians, especially in ultrasound, use the system to look at a patient s previous studies before proceeding 
with the current scan. 

■ Filing clerks use the system to print images for patients on paper, prefetch the previous studies of patients for 
scans scheduled the following day, and fulfill requests pertaining to in-pauent and emergency cases. 

• Clinicians use the system for clinical review of cases, for patient consultation, and to provide their patients 
printed hard copies of image data on dedicated plain paper printers located throughout the hospital. Clinical 
review stations axe used by surgeons in the operating room in place of film and a light box. 

• The image management team uses the system to troubleshoot image storage, and database problems, to manage 
system user accounts, and to check the contents of databases 

2.2.2. The Generic Server 

At the heart of the PACS is a generic DICOM-conformant server based on we Linux operating system (kerneis 
2.0.27-2.0.30, distributions RedHat 4.0-4.2) These serws run a suite of applications configured depending upon 
their role in the PACS. For example, a modality server runs an mSQL database server, a DICOM server based on 
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the MIR CTN library, 3 aa automatic routing daemon, a custom €-MO\"E process, a paper print server, a DICCV 
to. J PEG conversion process, and a WWW serrer to support the PACS browser. When a server is cooiigurec a, 
a rttneml servtr. used to retrieve data from CD, it runs three additional processes: two graphical applications i<> 
service archived image transfer and print, requests, and a daeinoo to process prefetches. Each server runs one or man- 
scripts, written in Perl, to moaner disk usage and automatically delete data and update databases. All servers run * 
suite of system-monitoring scripts called Big Brother 4 that track running processes, disk usage, processor load, swap 
space usage and several other parameters. Image management team members are notified by email if any of the** 
parameters exceed tolerance. 

The hardware configuration uf a typical server consists of an Intel Pentium Pro 2DQ or P-II 266 MHz processor 
with an ultra-vide SCSI Redundant Array of Inexpensive Disks (RAID) controller and a fast Ethernet network 
interface card. Hardware and storage are configured to suit the needs of the application. For example, a modalin 
server has five 9 gigabyte (GB) disks configured in a RAID level 5 array yielding about 32 GB of formatted storage 
capacity. Database servers employ two disks in a RAID-1 configuration which provides data redundancy without tb* 
write performance degradation exhibited by RAID-5. A retrieval server has a two-disk RAID-0 array which acts u 
a fast disk cache for data retrieved from CD-ROM. 

2.2.3. Modality Server 

Modality servers receive images from scanners and provide short-term storage within the PACS. There are current^ 
two servers dedicated to CT. one to MR and one to ultrasound. E ach machine is equipped with a RAID controuVr 
supporting a 5-disk RAID-o array which provides about 32 GB of formatted storage. Each modality server also ha- 
an IDE boot disk, a fast Ethernet card and 192 MB of EDO RAM. The DICOM application is both a storage Seme? 
Class Provider (SCP) and Service Class User (SCU), as well aa providing query/ retrieve services. 

Incoming images are stored on the RAID in a nested directory structure consisting of Patient ID and Studv 
Instance UID. Individual image names consist of the series number, image number and a random number to prevent 
the inadvertent overwriting of data by the system. A local database is written with demographic, study, series and 
image information as well as the specific path to the image daw. 

The DICOM server application supports several options that are determined at run-time: 

• Automatic Routing: images can be automatically routed to one or more destinations based on work-flow rules 

• Automatic Archival: series can be tagged for automatic archival to a dedicated archival server. 

• Immediate or delayed compression: images may be compressed immediately or have compression performed a: 
a later time by a separate process. 

• Teleradiology Functions: images can be tagged for conversion to JPEG format for in-line viewing via the lorai 
PACS browser. 

• Automatic Prefetch: an incoming study can automatically trigger the transfer of a previous study from long 
term storage. 

Modality servers also query the master database server to detennine if stored records have already been trans- 
f erred. Each modality server contains an exact copy of the master database structure. As images are received 
the DICOM server writes appropriate records to the local master database. A separate process determines if these 
records are already contained in the remote master database, inserts or updates them as necessary and deletes the 
local copy. By decoupling remote database storage from the DICOM software, the modality server can continue tc 
operate and store data even if the master database server is unavailable. 

The disk usage of the modality server is monitored by a script that runs in two modes. During the day, the scrips 
monitors disk capacity and intervenes to delete data only to keep the disk below the maximum capacity threshold 
At night, the same script deletes the oldest data from the RAID until it reaches the minimum capacity threshold 
which is calculated to give enough headroom for the scans of the following day. la this way, most of the overhead of 
data deletion and the associated database queries do not occur during peak hours. 
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2.2.4, Master Database Server 

The master database server runs the mSQL server application and houses the large central database that describes 
all data scanned siDce the PACS came into use. This database is queried chiefly by applications of the PACS browser 
as it has no DICOM capability. It employs a RAID-1 array for fast data transfers and data redundancy. It receives 
updates from applications on the modality servers thai transfer master database records. 

The conceptual unit of data in the system is the image series. Each series m the PACS, as identified by a DICOM 
unique identifier or UTD, has associated, with it one or more location record* in the master database. These location 
records tell PACS applications where the data can be found; e.g., on a modality server or on a specific volume oi 
archival media. Applications can then chcee the optimal location from which to retrieve the required data. 

The master database server also bouses an HL7 database which will become the core of the reporting system 
currently in development. The project encompasses the integration of mainframe demographic information ano 
orders with radiology reports and scanned images. 

2.2.5. Archival Server 

The archival server is used to receive images for long-term storage and tape backup. The nature of the chosen archive 
medium, recordable CD, requires that data be written to each CD in a batch-mode recording process. Recording ot 
CDs also requires the full use of the recording computer as any interruption of the data stream during the recording 
process will corrupt the CD, making it unreadable. These limitations led to a system design where CDs are recorded 
during the day and data are received from modality servers overnight. 

The archival server is similar in many respects to a standard modality server without capabilities such as automatic 
routing, WWW in-line viewing or printing. It acts as a storage SCP to the modality servers which send all series 
tagged during the day for overnight archival. The incoming images are stored in directories corresponding to the CD 
number where they will be located, and are compressed as they come in. An independent script, run by the cron 
facility, monitors each active CD directory (there is one active directory for each modality. CT. MR and US). When 
a directory reaches the limit for a recordable CD (about 650 MB) the CD number is incremented, a new directory 
created, and the control database changed to reflect the new storage location for that modality. 

After all modality servers have transferred their available data, another process runs which creates a table-of- 
contents file for the CD data and builds an ISO-9660 image fife of the directory suitable for recording on CD. The 
spooled, compressed data is also written to a backup tape which can be used to rebuild a CD, if lost or damaged 
An interactive program, run during the day, is used to record prepared image files onto blank CDs. This is the only 
part of the CD recording process that requires user intervention. All other operations are completely automated. 

The system has been designed in such a way that the choice of archive media is transparent to the rest of the 
system. In order to change media, we would simply have to make minor changes to the archival server software to 
accommodate the recording method. As the PACS grows and the amount of stored data increases, the burden on 
existing archival and retrieval resources has become apparent. We are anticipating the move to alternate media such 
as Digital Versatile Disk (DVD) in the near future and have also been evaluating Digital Linear Tape (DLT) for 
near-line storage. 
2.2.6. Retrieval Server 

The retrieval server is used by filing clerks to fulfill requests for data to be retrieved from long-term CD archive. The 
retrieval server can be thought of as a fully equipped modality server where the storage SCU is an application that 
reads data from CD, rather than a scanner. Two graphical X-windows applications are used to retrieve and distribute 
(or print) images from CD. Several other applications run behind the scenes to schedule and process requests that 
can be carried out without user intervention. Once data have been stored on the disk cache of the retrieval server, 
they are converted to JPEG format to become available for in-line viewing via the PACS browser 

The retrieval cache is monitored by a script that deletes the least recently retrieved series when the cache reaches 
capacity. As with the modality server, the disk monitor runs in two modes, daytime emergency monitoring and 
nighttime disk maintenance to reduce the computational and disk I/O burden on the server. 
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2.3, PACS Features 

2.3.1. Automatic Routing 

To provide work-flow management to the PACS, an application wi developed tu automatically route images to ihe 
locations where they are required As images Bre received from the scanner by the modality server, they are optionaih 
tagged for automatic routing by placing an entry in a routing database. A daemon process monitors this database 
and performs all image routing according to a set of routing roles, la our department, the radiologists are specialuea 
by anatomy, so reporting workstations have been assigned to anatomical categories of abdomen, bone, chest, ENT 
neuro, and spine. As well, some workstations are shared between groups. The routing rules accommodate these work 
schedules by routing specific scans to specific workstations at specified times. 

To accomplish this, scans are coded by anatomy at the scanner using the DICOM Study Description field. This 
information along with the date and time scanned and the workstation Est are used to identify the routing destination 
The images are then scheduled to be sent to the destination at the appropriate time as defined in the routing rules 

2.3.2. Cuatom C-MOVE Implementation 

Two problems were noted with the generic DICOM C-MOVE service class provided by the CTN library. Firstly 
the DICOM server is a multi-process application so a duplicate C-MOVE request could be issued repeatedly to the 
server and each request would be carried out regardless of the fact the the same data had been previously requested 
It was noticed early cm that, because of the nature of the workstation interface, users were repeatedly transferring 
the same data, which taxed the server, the workstation, and the network. Secondly, the generic implementation 
of C-MOVE did not give adequate feedback to the workstations or PACS browser of the success or failure of the 
C-MOVE request. 

To solve both these problems, the DICOM software was modified to piace C-MOVE requests in a separate 
database. Included in a database record are the ievei of the data requested (PATIENT. STUDY, SERIES, or 
IMAGE), the LTD of the data, the destination, and the date and time of the request. A database entry is formulated 
and its uniqueness is verified (the criteria fox duplication are level, LTD and destination). Any duplicate requests 
generate a C-MOVE response to the requestor with a status of 'Caned'. If a database record is written, the DICOM 
server returns a C-MOVE response to the requestor with a status of •Success' and the number of failed operations 
set to zero. 

A separate daemon monitors this database and fulfills all requests that are entered in it Series of data are 
transferred by separate sub-processes which monitor the status of each transfer Any failed transfers are reserved 
and repeated at a later time. This database C-MOVE facility is used by non-DICOM applications such as the PACS 
browser to make C-MOVE requests directly. 

To increase the reliability and performance of the system, another application running from a different server 
records the status of all DICOM storage SCPs on the PACS network by checking the result of a DICOM echo io 
each server's designated node and port number. This database of status information is used by DICOM applications 
to bypass storage SCPs that are currently unavailable. 

2.3.3. Image Conversion: OICOM to JPEG 

A modality server can optionally perform 'tekradiology' functions *hich involves the conversion of DICOM Images 
to JPEG format for viewing in a Web browser via resident WWW server software. Incoming images are tagged for 
conversion and a separate daemon processes the images as they are stored The JPEG images are indexed and used 
by the WWW server application for in-line image display 

2.3.4. Plain Paper Printing 

Each modality server and the retrieval server provide the facility to print i in-line images on postscript laser printers 
located in various areas of the hospital. This provides a hard-copy alternative to soft-copy viewing for clinicians and 
patients. The server runs a printing daemon and a script that monitors pnnt queues and gives feedback to users on 
the status of their print requests. 

The retrieval server also has ihe facility to print images directly from CD should the data only be available in 
long-terra storage. 
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2,3.5, Image Compression: Immediate or Delayed 





percent. 



Image compression is aeiayec. on modality servers and the retrieval server to move the high processing 
of compression away from peak usage periods. Typically, the arrival of an image at the modality servei 
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3.1. Data Redundancy 

One of the goals of our PACS project was to correct a weakness inherent in a conventional SJm system, the inevitable 
less of patient data. To this end, we have attempted in our design to build as much data redundancy into the system 
as budget and network constraints wili aiiow. 

The use of RAID technology has simplified the process by making data recovery as easy as replacing a failed disk 
and rebuilding the array without losing any data. This level of protection applies both to image data and databases 

CD archives are protected by recording an exact copy of the CD data onto DAT. Lost or damaged CDs can be 
replaced by simply restoring that data from CD, re-imaging the directory structure and re-recording the image, a 
two hour process. 

3.2. System Security 

Security issues have been addressed Ln several ways: 

• The DICOM-compliant systems use the Association class to authenticate earn SCU. This prevents unauthorizec 
hosts from accessing scanners or servers directly via the DICOM protocol. 

• The tnSQL databases employ host- and user-level access control to database servers to prevent unauthorized 
reading or writing of database records. 

• The WWW server uses both the host-level security built into the bttpd daemon and username/passworo 
(encrypted) authentication written into the WWW applications. 

The WWW server employs a system that rimes out a user login session after a specified period of inactivity. This 
prevents simultaneous logins to the same account. As well, users are forced to periodically change their passwords 
to enhance WWW system security. It is especially important that that WWW server security be robust as this 
application is available through the Internet. 
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3.3. Benefits of In-House Development 

The are several advantages to developing a PACS in-house: 

• Cost: the overall cost of an in- house solution including salaries anu capita, expenditures is still a fraction uf 
what vendors charge for a commercial solution. 

• Flexibility: in-house development allows the development team to respond quickly to user needs and to tailor 
solutions to user requirements. 

■ Ease of Integration: having a development team on-site reduces the problems associated with integrating 
cocQ-.erci&J hardware and software into the system. Vendor DICOM implementations are not always completely 
compatible and. as in our case, often require in-depth troubleshooting to identify points of failure. 

Well into the PACS project we received a request from another institution to have certain scans automatically 
routed to their workstation. Our routing operates at the image level, distributing images to various destinations 
using a 'round-robin' method. This ensures that no single destination will slow the pace of image distribution to ail 
workstations. It was discovered that the DICOM storage SCU Implementation for this particular workstation could 
not deal with a series of images spread over multiple associations, rendering the received data useless. Since we had 
complete control of development and implementation on the transmitting end. we were able to develop a gatewai 
machine (using a simplified version of the modality server software) that collated series before sending them to the 
workstation in question. 

Of course, the in-house approach requires that a business plan be formulated and a PACS development team put 
in place. These are not easy tasks to accomplish and require determination on the part of the radiology staff ana 
administration to see the project through. 

4. CONCLUSION 

Films were eliminated entirely in CI and MPJ in February of 1997 and ultrasounu has been filmless for more thax 
two years. In addition, the ultrasound mini- PACS has been converted to DICOM conformance while maintaining 
backward compatibility with archived data. 

The system continues to evolve as new technologies become available. As well, system performance is being exam- 
ined by gathering usage and data transfer statistics to aid in the refinement of the PACS design and implementation-'. 

By employing a distributed PACS design, we have spread network traffic and computational burdens evenly over 
inexpensive hardware in a comprehensive manner. The resulting system is a model for low-cost radiological image 
management. 
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ABSTRACT 

This paper describes the acquisition of usage statistics and analysis of data-flow patterns for our DlCOU-conformant 
PACS during its first year of operation. The system currently supports one MR, rune ultrasound, and three C7 
scanners, and has allowed our department to fully eliminate the production and use of film in these modalities. The 
aim was to not only aid in trouble-shooting, but to provide a means of examining usage patterns and quantifying 
data-Sow and storage requirements to help identify where refinements should be focused. Of particular interest 
were statistics quantifying turn-around times for user-initiated transfers and retrieval from long-term storage: the 
quantities of data acquired, moved, retrieved and prefetched, (sorted by modality and anatomy); usage patterns of 
clinicians within the hospital, and the quantity of data accessed via a WWW interface to our PACS. The results 
have been instrumental in refining our physical network plan, modifying retrieval and transmission algorithms, aad 
providing objective measures of the performance of our PACS. During the evolution of the system, the same data 
have allowed us to retrospectively examine whether certain modifications yielded improvements that were significant 
and whether expectations were met. The logging process continues since it is now relied upon as a tool for monitoring 
nearly all useful system parameters 

Keywords: PACS, usage statistics, performance, filmless radiology, DICOM 
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L. INTRODUCTION 

The Montreal General Hospital (MGH) Is a 500 bed level- 1 trauma center and is the Laigesiof four warning hospitils 
that are affiliated with McGLll University. During the last year, our department performed over 160.000 radiolog- 
ical exarnirtations. Approximately 40 percent of these were in CT, MRI and ultrasound, while the rest comprised 
conventional x-ray. mammography, fiuoroscopy and angiography. 

In late 1995, we developed and implemented an ultrasound mini-picture archive and communications system 
(PACS) to improve access to and management of image data, and to eliminate film. Baaed on the success of this 
system along with some strong clinical motivations, it was decided that it should be expanded to include CT and 
MRI. The PACS was subsequently redesigned to handle the larger volume of data and to conform to the Digital 
taajrin* and Commumcations in Medicine (DICOM) standard. In January of 1W7, the new system went into 
operation, supporting one MR, nine ultrasound, and two CT scanners. (A third CT scanner was added in May.) In 
February (1997), films in CT and MRI were eliminated. 

Because the system was developed in-house, we had the freedom to incorporate extensive logging to trace the 
flow of data and monitor system usage. While the resulting information proved useful in trouble-shooting early on. it 
became dear that it had value in measuring performance parameters that relate to system design and usage. Thus, 
the logging facility has become an integral part of our PACS and presently records all significant user-initiated actions 
along with system-generated operations that result in the transmission of image data throughout the network. 

This paper describes the acquisition of these data and the results covering the past year of operation. This 
information has provided insights that have helped guide the ongoing development of our PACS which, as described 
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below is best characterized as a distributed model. Here ** share the lessons learned through our design modificaticx.s 
along with figures pertaining to system usage, data volumes handled, and transmission raxes. These figures shou.c 
be useful in avoiding design pitfalls and helping to anticipate transmission and usage loads where models similar to 
ours are employed. 

2. METHODOLOGY 

2.1. Background 

Our current DICOM PACS grew out of the experience gained in developing our own ultrasound mini-PACS' wfajcfl 
was bawd predominately on a network of Macintosh computers. The latter system, which was not DICOM- 
coafbrmant until recently, employs 'capture stations' equipped with framegrabbers new to each ultrasound scanner 
(interlaced via an .VTSC video output on each scanner) which transmit the acquired images to a central 'server 
where they become available for viewing from any Macintosh on the departmental network. A master database keeps 
track of every study performed and allows users to quickly locate and retrieve prior examinations. For long-term 
archival, we employ recordable compact disks. 

While operating this mini-PACS, before deciding to include CT and MRI. several enhancements were introduce*) 
which ultimately are required by any effective PACS. These included rally automating the archival process (on CD) 
providing database searching tools that are integrated with the viewing software; providing a means of submitting and 
servicing requests for retrieval of data from long-term archive, and enabling access to the data from non-Macintosh 
computers outside the department. Together, these component satisfied the varied needs of the users and facilitateo 
the management of image data to the point where film was eliminated: one film processor was closed, and one clerk 
(previously dedicated to film-management) was reallocated to duties elsewhere. 

Concurrent to these developments, a group of our radiologists were exploring the merits of soft-copy re vie* 
practices in CT and MRI. After a six month trial, they concluded empirically that film-based review was inferior 
to soft-copy analysis. Thus, together with the success of the US mini-PACS, the decision to pursue development 
of a CT and MRI PACS seemed well justified. This time, it was decided that the new system should adhere to 
the DICOM standard to facilitate future upgrades and ease the integration of imaging equipment that would also 
be DICOM conformant. This necessitated a complete redesign. (See our companion paper in these proceedings foi 
more details. 1 ) 

2.2. PACS Design Overview 

Apart from tea commercial dual-monitor diagnostic review workstations (all Lnix-based), our entire PACS was 
developed in-house. Each component of the system is based upon IBM PC-compatible computers running the 
LINUX operating system (Red Hat distribution version 4.2). The choice to employ this combination of hardware 
and operating system stemmed partly from financial considerations (i.e.. PCs are relatively low in cost, and LINUX 
is free), but the choice was also based upon performance criteria that precluded the use of Macintosh and Windows 
95/NT systems. 

The core of our DICOM software was derived from the Malllncxrodt Institute of Radiology Central Test Node 
software, which is freely available in the public domain. For database software, we used mini-SQL', which is also 
available in the public domain. Several modifications were required to accommodate the archival of images oo 
CD. In particular, a 'Master Database* was introduced along with several disk space management applications. 
Additional modifications were made to incorporate automatic routing and prefetching capabilities, and to make 
DICOM query /retrieve operations more robust and manageable by the CPU under heavy loads. 

The PACS itself comprises several 'servers' dedicated to specific tasks The functional roles of each server are 
summarized in Table 1. 

The network presently runs lOOMBits/sec Ethernet with every server and each workstation on its own port of an 
Ethernet switch. When first deployed, the PACS was based on lOMBits/sec Ethernet with 2-3 workstations sharing 
each port of a lOllBits/sec Ethernet switch. 

The PACS presently serves 9 ultrasound scanners from various manufacturers, 3 CT scanners (2 of which required 
a commercial solution to become users of the DICOM Storage service class; the other is newer and has it built-in j. 
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Table 1, Summary of departments PACS servers and laeu functional roles. 



Modality Server 


- i for each scanner 

- DICO.M Storage SCU/SCP 
Query/Retrieve SCP 


- accepts unages from scanner 

- provides short- term storage 

- auto-routes images to 
appropriate destinations 

- auto-prefetches 

- services Query/ retrieves 

- accepts images from workstations 

- services print requests (paper) 

- provides WWW image viewing 


Archival Server 


- 1 for department 

- DICOM Storage SCP 


- accepts images from Modality Servers 

- automatically records data on CDs 


Retrieval Server 


- 1 for department 
DICOM Storage SCU 


- restores images from CD for 
re-distribution to other DICOM 
destinations 

- services print requests (paper) 

- provides WWW image viewing 

- coordinates all manual prefetching 
and scheduled routing 


Database Server 


1 for department 
no DICOM functions 


- pw"*»ln« Master Database to 
keep track of all studies performed 

eg, on-line, off-line (CD number) 


WWW Server 


- 1 for department 

- DICOM Storage SCP 


- provides WWW access to all 
images and Master Database 

• coordinates viewing image series, 
downloading, moving, searching, printing 

- several tools available 



and I MR scanner (a DICOM Storage SCU). Modality Servers aie distributed as follows: One for MRI. one tor 
the two older CT scanners; one for the third CT scanner, which is located in the Emergency Department, and one 
that serves the 9 ultrasound scanners. Images are transmitted automatically by every CT and MR scanner (and 
every US capture station) to the corresponding Modality Server where they are stored for several weeks (apprra. 90 
days). As each image is received, a copy a automatically routed to one or more DICOM destinations according to 
pre-defined rules that, in our case, depend primarily on the imaged anatomy. Since our radiologists are specialized 
by anatomy (rather than by modality, for example), we have chosen to designate the diagnostic review workstations 
accordingly. Thus, we have 2 abdominal; 2 bone/spine; 1 chest; 1 ENT and 2 neurological workstations, plus one 
dedicated to MRI and one dedicated to emergency CT cases. A copy of every scanned image is transmitted to the 
Archival Server to be recorded on CD, and until recently, a copy of every image was transmitted to the WWW Server 
to be available for viewing through the Internet. WWW access to the images is now distributed among the Modality 
Servers, allowing more images to remain immediateiy accessible and eliminating the need to transmit every image 
to the WWW Server. 

Each Modality Server provides several weeks of storage on hard disks that recently have been converted to employ 
RAID technology (level 5), After six months of operation, we decided to introduce the use of lossless compression 
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to extend the lifetime of the data oo-line (i.e.. on each Modality Server) as well as increase the effective capaary v 
the CDs used for long-term archival. The data, sorted by modality, are recorded on CD typically within 24 hours 
except for ultrasound which talces three to four days to fill one CD r . Once recorded and labeled, the CDs reside in 
the filing room in close proximity to the Retrieval Server which is equipped with two high-speed CD-ROMs. 

From the beginning, it was decided that we would examine the need for juke-box technology that would alio* 
data retrieval to be performed automatically. Thus, it was important to gather figures concerning the number of 
CDs handled each day and the times required to manually load them following audible notification. 

The WWW Server is * key component of our PACS. J Before ceasing to print films in CT and MRI. we recognizee 
the need to provide a means of allowing clinicians throughout our institution, as well as referring physicians froa: 
outside, to access the images. The decision to employ the Internet stemmed from several factors, including the 
growing familiarity of the population with the World Wide Web; the relatively intuitive interfaces of Web-browsers 
the readily available infrastructure, the desire to provide platform independent accessibility; and the ease of developing 
WWW interfaces. Cost was also a factor. By employing a Web-based interface to our PACS, we immediately made 
it possible to access images from any networked PC in the entire hospital without the additional costs associated 
with commercial viewing software. 

While the WWW Server was originally intended to serve the image viewing needs of users outside our department 
it quickly grew to provide several PACS management tools that axe now used by almost everyone. These include the 
ability to: move any study or series for any patient to any DICOM device known to our system (eg, workstations) 
download any series in its full resolution for analysis off-line: manually schedule the prefetching of prior studies; print 
any series (on paper only), and create teaching-files. Several other Web-based tools are employed to administer user 
accounts: modify automatic routing rules; monitor system usage and examine database contents. 

The Database Server maintains a 'Master Database' to record every patient examined and every study and series 
performed. It also maintains a record of the location(s) where the data reside (for example, which Modality Server 
they are on, and which CD they are stored on), and whether the data are on- or off-line. 

2.3, Data-Flow and Usage Measurements 

At the time of writing, we are completing the integration of our PACS and hospital information system (HIS) Onre 
put into operation, the link between images and reports will be available (through the WWW Server), along with 
additional related information. We expect system usage figures to increase dramatically, but we are presently unable 
to speculate on how much, 

2.3.1. Data acquisition 

The data studied in this paper can be grouped into one of three categories: Those related to data transfer rates and 
volumes: those describing retrieval response times, and those related to the frequency and type of user interactions 
(through the WWW Server). In every case, the data were gathered by making use of the logging facilities that 
are embedded in almost every application comprising the PACS. The mini-SQL database software was used for this 
purpose, greatly facilitating the retrieval of the desired quantities. 

2.4. Data Volumes 

Among the first questions we sought to answer was whether the departmental diagnostic review workstations bad 
been allocated equitably among the various anatomical specialties. This was a simple matter of examining data 
volumes in terms of the number of images acquired for each specialty. Although these numbers could be obtained 
from any one of several sources, they were most easily obtained by consulting the Master Database. 

Next, we were interested in obtaining figures describing the amount of image-based network traffic. This informa- 
tion, we believed, would be useful in balancing the load across the network by identifying whether a given Modal! rv 
Server was over- or under-utilized. In this case, we examined the number of user-initiated 'moves' (of series) from 
each Modality Server. Note that these 'moves' could be accomplished either through the WWW Server or through 
query /retrieval operations. The required data were obtained by recording details like the size, destination, and start 
and end transmission times for every series moved to a workstation or other DICOM device. 

'Refoie employing compression, we recorded one CD per d»Y foe e»ch Mod»i. ty Server, >ociudia< ul«**>uad. 
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2.5. Data Transfer Rates 

We were aiso interested to know more about image transfer rates between am servers and the workstations. Here, 
we examined only the data transfer rates tor user- initiated 'moves . We recorded the time when the user isaucd 
the move' command for & given series (i.e., start-lime), and the time when the entire series had been transmitted 
(i.e.. end-time). All times were measureo to the nearest second Transfer rates were competed from the size of 
each image transmitted and the difference between start- and end-times. As discussed below, these measurements 
were performed before and after some significant modifications were made to the network hardware and transmission 
software. 

2.6. Retrieval From Archives 

In order to study retrieval patterns from long-term storage, we gathered figures quantifying the number of CDs 
handled; the times to respond to retrieval requests (measured from the time a request is received to the time a CD 
is manually loaded), and the frequency of requests for data versus time since the study was performed. The first 
quantity was intended to provide an indication of the workload imposed upon the filing room staff, while the second 
quantity measured their performance Although our PACS had been in operation for only one year, the third study 
was intended to illustrate the degree to which older data are required which, m turn, has implication* conceromst, 
the amounts of on-line storage provided by the Modality Servers. 

2.T. WWW Server Usage 

In terms of usage measurements, we were limited to the actions thai are recorded for every user of the WWW Serve; 
These include tracking the identity of the user logged-in, along with the IP address of their computer; what database 
queries are performed; what studies and series are selected; what series are viewed, moved, printed, downloaded 
prefetched, or used to create a teaching file, and whether the desired data were available or had to be retrieved from 
CD. Every action is recorded with a time and date stamp to facilitate the generation of audit trails. 

Aa simple measures of overall use, we extracted several summary statistics over the most recent eight months 
These include the monthly totals of: new user accounts: logins including at least one query; series viewed; on- and 
off-line series moved (from a Modality Server to any known DICOM device); series printed, and series prefetched 

The WWW Server permits users to view any series of images whether on- or off-line. In the latter case, once the 
user asks to view a series, a request is sent immediately to the Retrieval Server and the user must wait for the data 
to be retrieved from CD (i.e., copied to the disks on the Retrieval Server). The images are then able to be viewed 
in JPEG format or downloaded in their native raw DICOM format. Images residing on the Modality Servers are 
available in both DICOM format and JPEG (the latter are immediately available for viewing). The generation of the 
JPEG images requires a conversion process from their original DICOM format. This process occurs automatically 
when each DICOM image is received on a Modality Server, or restored from CD. Thus, the selection of window 
widths and levels is automated In many cases, we had to derive suitable defaults for the various combinations of 
anatomy imaged and modality. Some minor image processing is also employed When viewed, the user is able tc 
specify their own window width and level, as well as raise and sort the images Changes in the window width or 
level require that the WWW Server regenerate temporary versions of the JPEC images from the corresponding full 
resolution DICOM images. 

At an indicator of whether the default window widths and levels are satisfactory, we examined the number of 
times users chose to make changes themselves. Because most users may not succeed in selecting appropriate values 
on their first try, we counted only one occurrence per displayed series per login session. 

Finally, we were interested in obtaining aa appreciation for the degree to which users actively use 'M r accounts 
on the WWW Server. For this purpose, we defined an account as 'active' if, at any given time, it had been accessed 
on at least two separate occasions within the most recent two weeks. In order to assess any trends, we determined 
the number of users with active accounts over the past eight months by taking measurements once per week. 

3. RESULTS 

At the time of writing, our PACS archive holds over 72.000 studies from 47,016 patients stored on approximately 
1500 CDs. The total number of registered users authorized to access our WWW Server is 481; 431 of which are 
affiliated with the McGill University Health Centre, while the rest (50) axe primarily outside referring physicians. 
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3,1. Data Volumes 

The data collected to study the issues described above are presented in the tables below. Figures describing tbe 
volumes of image data generated in CT and MRI for each anatomical specialty urtr preaentad in Table 2, Equivalent 
figures for ultrasound are omitted since the examinations, in our department, are typically not characterized by 
anatomical specialty. The figures for each anatomy were collected over a three month period and Include tbe mean 
number of studies performed per week: the total number of images per week and the mean number of images per 
study. 



Table 2. Volumes of data generated per week per anatomical specialty. Percentages of the totals in each modality 
are e.vpressed in parentheses 



j Abdomen [ Bone ) Chest [ E.VT 




Spine 


Other 


# itudies (CT) 


69 (21%) 


12 (4%) 


43 (13%) 


37 (12%) 


U8 (36%) 


39 (12%) 


7(2%) 


• # image* (CT) 


6297 (24%) 


1735 (7%) 


2894 (11%) 


5441 (21%) 


4476 (17%) 


4689 (18%) 


190(1%) 


mean iroates/itndy 


91 


142 


68 


145 


38 


122 


27 


# jtudie* (MR) 


15 (12%) 


■22(17%) 


0(0%) 


8(6*) 


45 (35%) 


21 (16%) 


18 (14%) 


# imas« (MR) 


2610 (17%) 


2473 (16%) 


0(0%) 


6*4(1%) 


6526 (41%) 


2345 (15%) 


1159 (7%) 


mean iro»ges/«ndy 




no 


0 


91 


144 


110 


66 


Tot*j 










#,tudi« (CT+MR) 


84 (19%) 


34(7%) 


43 (9%) 


45 (10%) 


163 (36%) 


60 (13%) 


25(6%) 


#un»«e* (CT+MR) 


8907 (21%) 


4208 (10%) 


2894 (T%) 


6125 (15%) 


11002 (26%) 


7034 (17%) 


1349 (3%) ! 



Table 3 presents the mean number of series trans nutted from each CT and MR Modality Server, per day. as a 
result of user-initiated requests. The table includes results for both before and after toe introduction of compression. 
Note that move requests may be generated either through the WWW Server or via direct DICOM query/retrieve 
operations. 

Table 3. Volumes of data transmitted from each Modality Server as a result of user- initiated "moves' (i.e., via the 
WWW Server or through DICOM query/retrieves). 'BC = Before compression. AC as After compression. 





MR Server j CT Server #1 | CT Server #2 


mean # of series moved (BC) 


144/day 


70/day ! 70/day 


mean # of series moved (AC) 


4«/day 


-13/day j 42/day 


median series size 


2.2 MB 


7.8 MB 11 MB 



3.2. Data Transfer Rates 

The transfer rates for user-initiated moves of images (or series) are presented in Table 4. Results are shown before 
and after some significant modifications were made to both the network and the software used to transmit the image 
data. 

3.3, Retrieval From Archives 

The results pertaining to the retrieval of data from long term archivr are as follows. The number of CDs requiring 
manual loading was determined by computing a daily average over the most recent one month period. Only weekdays 
were included. A total of 63 CDs (average) were loaded per day; 28 of which were for CT data; 12 for MRI. and 29 
for ultrasound. Prior to compressing data on both CD and on the Modality Servers, the figures for CT and MRI were 
46 and 19, respectively. The figure given for ultrasound (29), in fact, does not yet reflect tbe effect of compression 
since it was introduced only recently In other words, we expect to see it decrease. 
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Table 4. Image data transfer rates (in idiobytes/second) between Modajin Servers and workstations for user- 
initiated 'moves', Results are shown for transfer rates before acd after modifications that included converting from 
10 to 100MBits/sec Ethernet; changing the physical network layout, and making software enhancements. Note. The 
results for the .MR Server 'before modifications' were obtained while it employed lOMBits/sec Ethernet. All others 
employed lQOMBits/sec. 





MR Server 


CT Server #1 


CT Server #2 


Before Modifications 




median kbytes/sec 


32 


88 


S3 


mean kbytes/sec 


39 


91 


- M - 


Alter Modifications 




median kbytes/sec 




201 


190 


mean kbytes/aec 


239 


238 


209 



The median time elapsed between receiving a retrieval request and loading the required CD was 349 seconds for 
requests submitted between 7-17:00 hours. Between 17-24:00 hours, the median was 2,250 seconds. (The distinction 
between the day-shift and night-shift is explained in Section 4 below.) From midnight until 7AM, our filing room 
is closed and retrieval requests are not serviced. These figures were determined by monitoring all such activity over 
the most recent month. 

Figure 1 presents a histogram of the number of requests for data as a function of the time between when the 
examination was performed and when the request was submitted. These data were acquired as follows: For even, 
series moved, printed or prefetched by a user through the WWW Server, we determined the number of hours between 
the date and time the user issued the request and the date and time the series was created (i.e.. when the patient 
was imaged). The data were then binned in 24 hour intervals to generate the histogram. The thin curve at the top 
of the plot shows the integral sum of the number of series needed to date. 




FHgur« 1. Histogram plot illustrating the number of series required at any given tune as a function of the time since 
the series were acquired. The thin curve at the top of the plot shows the integral sum of the number of series needed 
to date. 
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3.4. WWW Server Usage 

The monthly totals of new user accounts created are listed in Table 5 The uumoer of logins (plus at least on* 
database query) per month are listed in Table 6, Also listed is the number of distinct users who logged "d made 
A t ieast one query, and the median number of logins per user per month. Table 7 lists the monthly total number 
of series viewed through the WWW Server, along with the corresponding number of distinct users and the mediae 
number of series viewed per user per month. Table 8 presents the equivalent figures for the total number of on-hne 
and off-line series moved (eg, from a Modality Server to a workstation). The number of series printed (on paper; 
per month, and the monthly totals of series prefetched axe listed in Tables 9 and 10, respectively. (Note: Printing 
on paper through the WWW Server became available in July. Prefetching became available in June.) 



Table 5. Monthly total number new user accounts created. 



May 


Jun 


Jul 


Aug 


Sep 


Oct 


Nov | Dec 


28 


38 


50 


41 


43 


38 


37 | 29 



Table 6. Monthly total number of logins (including at least 1 database query). 





May 


Jun 


Jul 


Aug 


Sep 


Oct 


Nov 


Dec 


total logins 


907 


837 


2792 


4120 


5371 


5765 


5897 


5733 


# distinct users 


72 


54 


115 


134 


163 


168 


180 


181 


logins/month/user (median) 5 


3 


10 


14 


14 


18 


16 


11 



Table 7. Monthly total number of series viewed through the WWW Server. 





May 


Jun 


Jul 


Aug 


Sep 


Oct 


Nov 


Dec 


total series viewed 


2155 


1621 


2335 


1954 


2630 


4248 


4507 


3719 


# distinct users 


93 


90 


98 


103 


134 


132 




141 


series/man th/uaer (median) 


9 


6 


6 


7 




12 


15 


9 



The number of times users chose to make changes to the default window widths and levels that are employed 
when viewing a series of images through the WWW Server was examined over the most recent 4 months. A total of 
15,104 series were viewed, Users chow to modify the window widths and levels at least once in 234 series. 

4. DISCUSSION 

It is important to realize when examining the results that there is a large number of influencing factors. Some expla- 
nations are simple, or obvious, like correlating holiday periods with system usage, or changing technical parameters 
tike CPU or network speeds. Others are much more difficult to identify. It is difficult, for example, to determine 
whether the increasing use of the WWW Server is due to growing user acceptance or simply the growing number 
of users. Another confounding factor is that the PACS is continuing to evolve, providing more tools and better 
interfaces to existing ones. So rather than attempt to isolate some of the more complex causes and effects, we have 
focussed on what we believe to be larger details. 

The first among these was to verify that the departmental diagnostic review workstations had been allocated 
equitably. Using Table 2 to rank the various anatomical specialties on the basis of total studies (CT+MR) yields the 
following (from highest to lowest) Neuro (163); Bone/Spine (94); Abdomen (84); ENT (45); Chest (43) and Other 



HOPITflL DE CflRftQUET LWjEN 
CA 02244549 1998-08-04 



Table <*. Monthly total number of on-line and off-line series moved. 





May 


Jun | Jul 


Aug 


Sep 


Oct 


Nov 


Dec 


on-line series moved 


1097 


950 


3531 


4274 


7506 


5986 ! 7335 


5617 


# distinct users 


53 


6? 


75 


86 


113 


107 


118 


116 


series/montn/user (median) 


5 


6 


11 


14 


8 


11 


U 


3 


off-line series moved 


2930 


1715 


2808 


3672 


5037 


5949 


6180 


3726 


# distinct users 


63 


71 


72 


76 


101 


114 


119 


95 


•aries/month/usei (median) 


10 


7 




10 


12 


17 


U 


10 



Table 9. Monthly total number of series printed (on paper). 





Jul 


Aug 


Sep 


Oct 


, Nov 


Dec 


total series printed 


398 


814 


900 


886 


939 


735 


# distinct users 


19 


34 


37 


47 


53 


48 


series/month/user (median; 


3 


4 


5 


6 i 7 


6 



(25). Neuro and Bone/Spine exchange their rankings if the total number of images is considered. Given that earn 
specialty must be provided with at least one workstation and that there must be one dedicated workstation for MR1 
aad one for the Emergency CT scanner. 3 are left to be distributed. Giving one each to Abdomen. Bone/Spine ana 
Neuro is most equitable, which confirms that the workstations were allocated properly to begin with. 

During the first four months of operating our PACS with CT and MRI, we had only two Modality Servers: One 
shared by our CT scanners, and one for MRI. Upon namining Table 3, which describes the number of series moved 
by users from each Modality Server oa a daily basis, it appears at first that the two CT Modality Servers perform 
naif the work of the MR Server However, by taking into account the size of the series transferred, it is clear that 
the CT Servers move a greater volume of data (measured In MB) each day than is moved in MRI. 

After introducing compression to increase the amount of data, residing on-line, the number of series moved 
decreased by almost a factor of two in CT, and a factor of three in MRI At first, this might seem unexpected 
since having more data on-line should increase the likelihood of a series being moved. The explanation, we believe, 
is two-fold; First, the local storage on the WWW Server was increased by adding the use of compression along 
with one 9GB bard disk. At the time, images could only be viewed from the WWW Server. So they had to be 
transmitted there if they were not already present. Thus, the larger capacity of the WWW Server reduced the 
number of images needed to be transferred from the Modality Servers. Secondly, if the previous study for a patient 
undergoing a repeat examination was itiil on-line and was required for comparison, the manual prefetching command 
generated the equivalent of a 'move'. With the addition of automatic prefetching (coinciding with the introduction 
of compression), fewer studies had to be moved manually. While the same quantity of data might still flow from the 
Modality Servers, the relative volume of data moved manually has decreased. 

The results presented in Table 4 showing the image data transfer rates for user-initiated moves are particularly 



Table 10. Monthly total number of series prefetched. 





Jun 


Jul 


Aug 


Sep 


On 


Nov 


Dec 


total series prefetched 


304 


671 


798 


956 


:347 


1326 




# distinct users 


3 


4 


4 


3 


3 
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interesting. In the 'before modifications' category, the results for the MR Modality Server are surprisingly poor. One 
explanation is that these results were gathered while the server was still on a iO.MBits/sec Ethernet segment soared 
by the MRI scanner, and the two were linked to the rest of the PACS by one coa.-dai cable that was shared by several 
other computers (non-servers) in the department. The corresponding results for the two CT Modality Servers were 
obtained after they had been upgraded to lOOMBits/sec Ethernet, but the relathe improvement over the MR Server 
was only a factor of approximately 3. Still, the results were surpnsicgly poor (approx, 90kb/sec)- The explanation 
for these results, and the more than two-fold increase shown in the 'after modifications' category, lies in a change 
that was made to the application responsible for transmitting the images. Previously, this application had been 
over-engineered in an attempt to reduce the load on the Modality Server CPUs and to provide complete immunity 
to transmission interruptions. These goals were achieved by keeping a record of which images bad been transmitted 
successfully and permitting only a single image to be transmitted at a time. This meant that a DICOM association 
vi-as opened and closed for every image sent. The resulting overhead is most significant when transmitting large series 
of images and accounts for the factor of two increase in speed. The apparent six-fold increase for MRI is due to both 
the change from lOMBits/sec Ethernet and the newer algorithm. 

The figures describing the number of CDs manually loaded per day illustrate vividly the benefits of compression. 
The argument for not employing compression earlier had been that it would slow down the already slow process of 
restoring data from CD to the local hard disk. After conducting some tests to determine the additional fraction of 
time required to uncompress several large series of images, we were surprised to find that there was no measurable 
difference. However, the time required to compress the images was much greater than expected, placing a significant 
burden on the CPU if performed during peak hours 

The median time required to load a CD during the day (349 seconds) was ru'gher than expected. Beyond 17:00 
hours, only one clerk remains on duty and prefetching of previous ultrasound cases is done for the following day. 
(Prefetching in CT and MRI is fully automated.) The dramatic increase in response time (2250 seconds = 37-5 
minutes) was also surprising ana seems to be due to a reduced sense of urgency to service the requests. Consequently, 
the prefetching task has been spread more evenly across the day and night shifts. 

The histogram in Figure I illustrates the frequency of requests for images as a function of the difference in 
rime between the corresponding study date and whan the request was issued. The plot is intended to provide an 
indication of the period of time most data are needed following a given examination. Knowing the length of time 
images remain on-line on the Modality Servers, this plot should allow the volume of off-line data requested to be 
predicted. Conversely, if a maximum number of studies to be retrieved from CD per day is specified, the plot should 
allow the optimum amount of disk space allocated for on-line storage to be determined. It can be sees that the 
current storage capacity of our Modality Servers (approx. 90 days) is sufficient to account for nearly 75 percent of 
the data required. Since we would like this figure to approach to 90 percent, we would have to double the storage 
capacity of the Modality Servers 

The results collected describing the usage of the WWW Server were also very telling. With nearly 500 registered 
users, the total continues to grow at over 30 new accounts per month (not counting December because of holidays) 
The rise in the oumber of new user accounts created during the summer months was easily explained: The new 
clinical residents arrived in June, and 15 new PC-based workstations were provided for image viewing in several of 
the clinics and operating theatres in the hospital. 

Table 6 shows the increasing number of people using the system (i.e., logging- in and performing at least one 
database query). The most rapid growth occurred during the summer, going from 907 logins per month in May to 
over 5000 per month by September. The number of distinct users per month and their median number of logins 
grew in the same manner. By the end of the summer, the number of distinct users per month was approximately 45 
percent of the total number of registered users, and each employed the WWW Server (on average) every other day. 

A similar trend is seen in Table 7 which shows the number of image series viewed per month. Table 6 shows the 
number of on-line and off-line series moved per month by users. Although the numbers seem to reach a plateau, they 
are alarmingly high given that they do not include network traffic due to automatic image routing and prefetching. 
It turns out that a large number of these moves were directing images to the WWW Server to be viewed. Thus, »n 
order to reduce (in fact, eliminate) this traffic, we decided to distribute the WWW image display task among the 
Modality Servers and the Retrieval Server where most of the images reside. Although we do not have results, we 
expect the figures describing the number of series moved to change dramatically This modification may also affect 
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Figure 2, Bar plot illustrating che number of 'active' users of the WWW Saver during the weeks from May througa 
December. 

several other results. The reduced network traffic may improve image transfer times, and the immediate availabilitv 
of images for viewing where previously the user had to wait may improve user acceptance. 

Table 9 shows the monthly total number of series printed on paper. The rapid jump from 398 to 814 series between 
July and August coincided with the introduction of several new laser printers (dedicated to printing images) In kev 
locations throughout the hospital The current number of series printed per month (approx. 900) Is disappointing 
This number is approximately 25 percent of the number of series viewed through the WWW Server. The most likely 
reasons for these results are that a significant number of users have not yet become accustomed to soft-copy viewing 
(or are unwilling to try); they lack access to an adequate computer, or they are dissatisfied with the display function 
itself. Certainly, the inability to modify the displayed window width and level settings in real-time is a barrier. In 
order to address this issue, we will soon be distributing more sophisticated image viewing software throughout our 
hospital. 

The number of series prefetched per month and the number of distinct users doing the prefetching are presented 
in Table 10. From June to October there is a steady increase in the number of series prefetched, then it appears 
to stabilize in November. In December, the figure suddenly doubles. The latter is easily explained: The ultrasound 
rami-PACS was integrated with the CT and MR in December, and both now employ the same prefetching scheme 
Thus, the surplus of prefetched series is attributable to ultrasound. The increase in the number of distinct users 
doing prefetching reflects the participation of our ultrasound technicians who were accustomed to the older PACS 
The steady increase noted from June to October is explained as follows; Image data in CT and MRI began to be 
archived on CD in January. Thus, although the same number of studies were performed every month, the amount 
of digital data that could be prefetched from CD had to accumulate. In the earliest days, for example, the vast 
majority of previous cases had existed only on film. 

Out of 15,104 series viewed through the WWW Server over the past 4 months, the user changed the window 
width and levels 234 times (i.e., 2 percent of the time). This would seem to indicate that the default values were 
acceptable the great majority of the time. However, it might also indicate that most users do not understand how, 
or have the patience, to change the values manually. 

Finally, the increase in use of the WWW Server over the months is clearly seen in Figure 2, While some of the 
other results are sensitive to the actions of single users, this quantity is a more accurate reflection of the increasing 
load due to new users and those that may use the WWW Server more often over time. 
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Figure 2, Bar plot illustrating the number of 'active' users of the WWW Server during the weeks from May througn 
December. 



several other results. The reduced network traffic may improve image transfer times, and the immediate availability 
of images for viewing where previously the user had to wait may improve user acceptance. 

Table 9 shows the monthly total number of series printed on paper. The rapid jump from 398 to 814 series between 
July and August coincided with the introduction of several new laser printers (dedicated to printing images) in kev 
locations throughout the hospital The current number of series printed per month (approx. 900) Is disappointing. 
This number is approximately 25 percent of the number of series viewed through the WWW Server. The most likely 
reasons for these results are that a significant number of users have not yet become accustomed to soft -copy viewing 
(or are unwilling to try); they lack access to an adequate computer, or they are dissatisfied with the display function 
itself. Certainly, the inability to modify the displayed window width and level settings in real-time is a barrier. In 
order to address this issue, we will soon be distributing more sophisticated image viewing software throughout our 
hospital - 

The number of series prefetched per month and the number of distinct users (ioing the prefetching are presented 
in Table 10. From June to October there is a steady increase in the number of series prefetched, then it appears 
to stabilize in November, in December, the figure suddenly doubles. The latter is easily explained: The ultrasound 
rnini-PACS was integrated with the CT and MR in December, and both now employ the same prefetching scheme 
Thus, the surplus of prefetched series is attributable to ultrasound. The increase in the number of distinct users 
doing prefet ching reflects the participation of our ultrasound technicians who were accustomed to the older PACS. 
The steady increase noted from June to October is explained as follows: Image data in CT and MBI began to be 
archived on CD in January. Thus, although the same number of studies were performed every month, the amount 
of digital data that could be prefetched from CD had to accumulate. In the earliest days, for example, the vast 
majority of previous cases had existed only on film. 

Out of 15,104 series viewed through the WWW Server over the part 4 months, the user changed the window 
width and levels 234 times (i.e., 2 percent of the time). This would seem to indicate that the default values were 

acceptable the great majority of the time. However, it might also indicate that most users do not understand how, 

or have the patience, to change the values manually. 

Finally, the increase in use of the WWW Server over the months is clearly seen in Figure 2. While some of the 

other results are sensitive to the actions of single users, this quantity is a more accurate reflection of the increasing 

load due to new users and those that may use the WWW Server more often over time. 
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5. CONCLUSIONS 

This paper lias presented an overview of our DICOM-confonaant PACS aiong with ao analysis of data-flow ana 
usage statistics gathered during its first year of operation. The generation of these results was facilitated by having 
incorporated detailed logging of transmission events and user-initiated actions directly into the PACS and its WWW 
interface. Initially, the rationale for gathering such detailed information derived from the need to facilitate debug 
ging and to collect audit trails for every user to satisfy hospital security concerns. It soon became clear that this 
information also allowed us to objectively assess the performance of the PACS while it continued to evolve. 

In several cases, analysis of the information gathered allowed us to identify system faults and weaknesses that did 
not manifest themselves openly. Examples of these include discovering that one Modality Server was operating on a 
lOMBits/sec Ethernet segment when it was thought to be working at I0OMBits/sec. An analysis of image transfer 
rates identified this problem. On another occasion, automatic Image rooting was accidentally con fusi n g ENT and 
emergency cases such that the emergency cases were (erroneously) routed to the ENT workstation. An analysis oi 
data volumes routed identified this error. At one point, an inordinately high number of CD retrievals were repeatedly 
Issued over a period of several days. A clerk in a different department was later identified from the WWW Server 
usage logs as being responsible. The confusion in this case was due to a misunderstanding over which cases were 
Deeded to prepare for rounds. 

The statistics we gather also allow us to anticipate the load placed on the PACS by the increasing total number 
of users. A recent design modification has distributed the WWW image display task across the Modality Servers 
This new scheme minimally increases the CPU load on each Modality Server, but it virtually eliminates all network 
traffic (i.e., DICOM image transfers) due to users from outside of our department. It has also liberated the WWW 
Server to handle only WWW connections and database queries while previously it also received DICOM images from 
every Modality Server and converted them to JPEG format images. We are now gathering information to study the 
effects of this modification. 

In this respect, building the logging facility into our PACS has been invaluable. It too continues to evolve 
not just providing information concerning new features of the PACS, but is being refined to capture more detailed 
information in ways that make analysis easier. The recently implemented gateway between our PACS and HIS wili 
allow us to provide more than just images to our users, so we expect a significant increase in system usage. The 
ability to monitor this in the months ahead should prove useful in adapting the new utilities to the needs of the users 
and rapidly addressing any oversights. 



